home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1993 July / Internet Tools.iso / RockRidge / mail / pine / imap_archive / text0015.txt < prev    next >
Encoding:
Text File  |  1993-07-02  |  5.0 KB  |  102 lines
  1.  Steve Hole <steve@edm.isac.ca> writes:
  2. >2.  Who is responsible for the development of the message management
  3. >protocol? Is there a mailing list for this?  What is the status of
  4. >this effort?
  5. The CMU team (John Myers and myself) have agreed to spearhead the
  6. design of this protocol.  We have just finished our survey of user
  7. requirements on campus, and have a final functional requirements
  8. document for the mail system we will need here (and a draft design
  9. document).
  10.  
  11. I expect us to start design of the protocol in a month or so, and you
  12. _might_ see an implementation in a year.  The protocol is likely to be
  13. very similar to IMAP2bis (probably with some of the same commands for
  14. subscriptions & such).
  15.  
  16. >    This is becoming a real issue for us.  The ability to get and
  17. >configure services like delivery acknowledgement, read
  18. >acknowledgments, and automatic reply are a high priority for many of
  19. >our clients - especially when packages like Microsoft mail are able to
  20. >do it.
  21. Delivery acknowledgements are useless (the message will bounce if not
  22. delivered).  Read acknowledgements, and reply are client issues.  If
  23. by "automatic reply" you mean something like the unix vacation
  24. service, we have that rated as "NICE" meaning we'll consider it if we
  25. get time (I think putting support for it in either the management
  26. protocol or the user directory protocol is reasonable).
  27.  
  28. >4.  Is there an agreement or description of where services like
  29. >automatic reply should be provided - in the MTA or the MUA?  X.400
  30. >specifies the message store (which makes sense), but there is no
  31. >equivalent in the Internet architecture (I think there should be).
  32. Anything that can go in the MUA should, IMHO.  Keeping the MTA &
  33. mailstore simple and easy to maintain is very important.  Things like
  34. vacation replies, and automatic filing of incoming mail will probably
  35. be put at the mailstore end of the MTA.
  36.  
  37. >5.  There was some mention on work being done to implement
  38. >lightwieght directory access protocols for getting X.500 information
  39. >quickly.  Could someone point me to these individuals again?  This is
  40. >very important to us as a mechanism for distributing public keys for
  41. >PEM.
  42. There's a protocol called CSO/ph which we're going to look into.  If
  43. it's not good enough, we'll design & write our own.
  44.  
  45.         - Chris Newman
  46.         Carnegie Mellon University Computing Services
  47. From imap-request@cac.washington.edu  Mon Sep 28 00:34:47 1992
  48. Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu
  49.     (5.65/UW-NDC Revision: 2.27 ) id AA25738; Mon, 28 Sep 92 00:34:47 -0700
  50. Received: by mx1.cac.washington.edu
  51.     (5.65/UW-NDC Revision: 2.27 ) id AA03437; Mon, 28 Sep 92 00:34:42 -0700
  52. Errors-To: imap-request@cac.washington.edu
  53. Sender: imap-request@cac.washington.edu
  54. Received: from tomobiki-cho.cac.washington.edu by mx1.cac.washington.edu
  55.     (5.65/UW-NDC Revision: 2.27 ) id AA03431; Mon, 28 Sep 92 00:34:38 -0700
  56. Return-Path: <MRC@Panda.COM>
  57. Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU
  58.     (NX5.67c/UW-NDC Revision: 1.60.MRC ) id AA04375; Mon, 28 Sep 92 00:34:27 -0700
  59. Received: from localhost by Ikkoku-Kan.Panda.COM
  60.     (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA01527; Mon, 28 Sep 92 00:34:21 -0700
  61. Date: Mon, 28 Sep 1992 00:23:08 -0700 (PDT)
  62. From: Mark Crispin <MRC@Panda.COM>
  63. Subject: re: Some general mail message issues
  64. To: Steve Hole <steve@edm.isac.ca>
  65. Cc: IMAP Interest List <IMAP@CAC.Washington.EDU>, pine-info@cac.washington.edu
  66. In-Reply-To: <Pine.3.03.9209251156.A21395-c100000@isasun-3>
  67. Message-Id: <MailManager.717664988.1433.mrc@Ikkoku-Kan.Panda.COM>
  68. Mime-Version: 1.0
  69. Content-Type: TEXT/PLAIN; charset=US-ASCII
  70.  
  71. On Fri, 25 Sep 1992 11:05:56 -0600, Steve Hole wrote:
  72. > 1.  Is there a mailing list for the discussion of the MIME message format?
  73.  
  74. The mailing list for MIME is IETF-822@dimacs.Rutgers.EDU.
  75.  
  76. The issue of integration of PEM with MIME is right now being discussed within
  77. an `internal group' of MIME/PEM folks.  You can check with Marshall Rose or
  78. Einar Stefferud to get a current status.  Presently, PEM in MIME is not
  79. formally defined yet, so you should not be doing any implementations unless
  80. you're prepared to be one of the pioneers with arrows in their backs.
  81.  
  82. I hope that Chris Newman answered questions 2-6 to your satisfaction.
  83.  
  84. > 6.  Is there a todo list for the c-client?
  85.  
  86. Yes.  It's much longer than I would like it to be.
  87.  
  88. > What are the current priorities for the c-client?
  89.  
  90. The current focus is to get acceptable DOS/Mac clients going and in particular
  91. to get PC Pine ready for prime time.  I just finished the code to allow local
  92. file MIME parsing in DOS without requiring you to have the entire message in
  93. memory.  We have a DOS local file format driver; pretty much the mail.txt
  94. format.  None of us are very happy with it; I think we need more of an mh
  95. style format, while my boss wants a /usr/spool/mail format.  Fortunately, c-
  96. client allows you to write as many drivers as you want.
  97.  
  98. I hope to be able to get back to development (I don't consider DOS ports
  99. `development') and in particular getting IMAP2bis fully implemented in c-
  100. client Real Soon Now.
  101.  
  102.